home *** CD-ROM | disk | FTP | other *** search
EEEELLLLFFFF((((3333EEEE)))) EEEELLLLFFFF((((3333EEEE)))) NNNNAAAAMMMMEEEE _eeee_llll_ffff - object file access library SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS _cccc_cccc [_f_l_a_g ...] _f_i_l_e ... _----_llll_eeee_llll_ffff [_l_i_b_r_a_r_y ...] _####_iiii_nnnn_cccc_llll_uuuu_dddd_eeee _<<<<_llll_iiii_bbbb_eeee_llll_ffff_...._hhhh_>>>> DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN Functions in the ELF access library let a program manipulate ELF (Executable and Linking Format) object files, archive files, and archive members. The header file provides type and function declarations for all library services. Programs communicate with many of the higher-level routines using an _E_L_F _d_e_s_c_r_i_p_t_o_r. That is, when the program starts working with a file, _eeee_llll_ffff______bbbb_eeee_gggg_iiii_nnnn creates an ELF descriptor through which the program manipulates the structures and information in the file. These ELF descriptors can be used both to read and to write files. After the program establishes an ELF descriptor for a file, it may then obtain _s_e_c_t_i_o_n _d_e_s_c_r_i_p_t_o_r_s to manipulate the sections of the file [see _eeee_llll_ffff______gggg_eeee_tttt_ssss_cccc_nnnn(3E)]. Sections hold the bulk of an object file's real information, such as text, data, the symbol table, and so on. A section descriptor ``belongs'' to a particular ELF descriptor, just as a section belongs to a file. Finally, _d_a_t_a _d_e_s_c_r_i_p_t_o_r_s are available through section descriptors, allowing the program to manipulate the information associated with a section. A data descriptor ``belongs'' to a section descriptor. Descriptors provide private handles to a file and its pieces. In other words, a data descriptor is associated with one section descriptor, which is associated with one ELF descriptor, which is associated with one file. Although descriptors are private, they give access to data that may be shared. Consider programs that combine input files, using incoming data to create or update another file. Such a program might get data descriptors for an input and an output section. It then could update the output descriptor to reuse the input descriptor's data. That is, the descriptors are distinct, but they could share the associated data bytes. This sharing avoids the space overhead for duplicate buffers and the performance overhead for copying data unnecessarily. FFFFIIIILLLLEEEE CCCCLLLLAAAASSSSSSSSEEEESSSS ELF provides a framework in which to define a family of object files, supporting multiple processors and architectures. An important distinction among object files is the _c_l_a_s_s, or capacity, of the file. The 32-bit class supports architectures in which a 32-bit object can represent addresses, file sizes, etc., as in the following. Name Purpose _______________________________________ _EEEE_llll_ffff_3333_2222______AAAA_dddd_dddd_rrrr Unsigned address _EEEE_llll_ffff_3333_2222______HHHH_aaaa_llll_ffff Unsigned medium integer _EEEE_llll_ffff_3333_2222______OOOO_ffff_ffff Unsigned file offset |||| PPPPaaaaggggeeee 1111 EEEELLLLFFFF((((3333EEEE)))) EEEELLLLFFFF((((3333EEEE)))) _EEEE_llll_ffff_3333_2222______SSSS_wwww_oooo_rrrr_dddd Signed large integer _EEEE_llll_ffff_3333_2222______WWWW_oooo_rrrr_dddd Unsigned large integer _uuuu_nnnn_ssss_iiii_gggg_nnnn_eeee_dddd _cccc_hhhh_aaaa_rrrr Unsigned small integer _______________________________________ |||| Other classes will be defined as necessary, to support larger (or smaller) machines. Some library services deal only with data objects for a specific class, while others are class-independent. To make this distinction clear, library function names reflect their status, as described below. DDDDAAAATTTTAAAA RRRREEEEPPPPRRRREEEESSSSEEEENNNNTTTTAAAATTTTIIIIOOOONNNNSSSS Conceptually, two parallel sets of objects support cross compilation environments. One set corresponds to file contents, while the other set corresponds to the native memory image of the program manipulating the file. Type definitions supplied by the header files work on the native machine, which may have different data encodings (size, byte order, etc.) than the target machine. Although native memory objects should be at least as big as the file objects (to avoid information loss), they may be bigger if that is more natural for the host machine. Translation facilities exist to convert between file and memory representations. Some library routines convert data automatically, while others leave conversion as the program's responsibility. Either way, programs that create object files must write file-typed objects to those files; programs that read object files must take a similar view. See _eeee_llll_ffff______xxxx_llll_aaaa_tttt_eeee(3E) and _eeee_llll_ffff______ffff_ssss_iiii_zzzz_eeee(3E) for more information. Programs may translate data explicitly, taking full control over the object file layout and semantics. If the program prefers not to have and exercise complete control, the library provides a higher-level interface that hides many object file details. _eeee_llll_ffff______bbbb_eeee_gggg_iiii_nnnn and related functions let a program deal with the native memory types, converting between memory objects and their file equivalents automatically when reading or writing an object file. EEEELLLLFFFF VVVVEEEERRRRSSSSIIIIOOOONNNNSSSS Object file versions allow ELF to adapt to new requirements. Three- independent-versions can be important to a program. First, an application program knows about a particular version by virtue of being compiled with certain header files. Second, the access library similarly is compiled with header files that control what versions it understands. Third, an ELF object file holds a value identifying its version, determined by the ELF version known by the file's creator. Ideally, all three versions would be the same, but they may differ. If a program's version is newer than the access library, the program might use information unknown to the library. Translation routines might not work properly, leading to undefined behavior. This condition merits installing a new library. PPPPaaaaggggeeee 2222 EEEELLLLFFFF((((3333EEEE)))) EEEELLLLFFFF((((3333EEEE)))) The library's version might be newer than the program's and the file's. The library understands old versions, thus avoiding compatibility problems in this case. Finally, a file's version might be newer than either the program or the library understands. The program might or might not be able to process the file properly, depending on whether the file has extra information and whether that information can be safely ignored. Again, the safe alternative is to install a new library that understands the file's version. To accommodate these differences, a program must use _eeee_llll_ffff______vvvv_eeee_rrrr_ssss_iiii_oooo_nnnn to pass its version to the library, thus establishing the _w_o_r_k_i_n_g _v_e_r_s_i_o_n for the process. Using this, the library accepts data from and presents data to the program in the proper representations. When the library reads object files, it uses each file's version to interpret the data. When writing files or converting memory types to the file equivalents, the library uses the program's working version for the file data. SSSSYYYYSSSSTTTTEEEEMMMM SSSSEEEERRRRVVVVIIIICCCCEEEESSSS As mentioned above, _eeee_llll_ffff______bbbb_eeee_gggg_iiii_nnnn and related routines provide a higher-level interface to ELF files, performing input and output on behalf of the application program. These routines assume a program can hold entire files in memory, without explicitly using temporary files. When reading a file, the library routines bring the data into memory and perform subsequent operations on the memory copy. Programs that wish to read or write large object files with this model must execute on a machine with a large process virtual address space. If the underlying operating system limits the number of open files, a program can use _eeee_llll_ffff______cccc_nnnn_tttt_llll to retrieve all necessary data from the file, allowing the program to close the file descriptor and reuse it. Although the _eeee_llll_ffff______bbbb_eeee_gggg_iiii_nnnn interfaces are convenient and efficient for many programs, they might be inappropriate for some. In those cases, an application may invoke the _eeee_llll_ffff______xxxx_llll_aaaa_tttt_eeee data translation routines directly. These routines perform no input or output, leaving that as the application's responsibility. By assuming a larger share of the job, an application controls its input and output model. LLLLIIIIBBBBRRRRAAAARRRRYYYY NNNNAAAAMMMMEEEESSSS Names associated with the library take several forms. _eeee_llll_ffff______n_a_m_e These class-independent names perform some service, _n_a_m_e, for the program. _eeee_llll_ffff_3333_2222______n_a_m_e Service names with an embedded class, _3333_2222 here, indicate they work only for the designated class of files. _EEEE_llll_ffff______T_y_p_e Data types can be class-independent as well, distinguished by _T_y_p_e. PPPPaaaaggggeeee 3333 EEEELLLLFFFF((((3333EEEE)))) EEEELLLLFFFF((((3333EEEE)))) _EEEE_llll_ffff_3333_2222______T_y_p_e Class-dependent data types have an embedded class name, _3333_2222 here. _EEEE_LLLL_FFFF______CCCC______C_M_D Several functions take commands that control their actions. These values are members of the _EEEE_llll_ffff______CCCC_mmmm_dddd enumeration; they range from zero through _EEEE_LLLL_FFFF______CCCC______NNNN_UUUU_MMMM_----_1111. _EEEE_LLLL_FFFF______FFFF______F_L_A_G Several functions take flags that control library status and/or actions. Flags are bits that may be combined. _EEEE_LLLL_FFFF_3333_2222______FFFF_SSSS_ZZZZ______T_Y_P_E These constants give the file sizes in bytes of the basic ELF types for the 32-bit class of files. See _eeee_llll_ffff______ffff_ssss_iiii_zzzz_eeee for more information. _EEEE_LLLL_FFFF______KKKK______K_I_N_D The function _eeee_llll_ffff______kkkk_iiii_nnnn_dddd identifies the _K_I_N_D of file associated with an ELF descriptor. These values are members of the _EEEE_llll_ffff______KKKK_iiii_nnnn_dddd enumeration; they range from zero through _EEEE_LLLL_FFFF______KKKK______NNNN_UUUU_MMMM_----_1111. _EEEE_LLLL_FFFF______TTTT______T_Y_P_E When a service function, such as _eeee_llll_ffff______xxxx_llll_aaaa_tttt_eeee, deals with multiple types, names of this form specify the desired _T_Y_P_E. Thus, for example, _EEEE_LLLL_FFFF______TTTT______EEEE_HHHH_DDDD_RRRR is directly related to _EEEE_llll_ffff_3333_2222______EEEE_hhhh_dddd_rrrr. These values are members of the _EEEE_llll_ffff______TTTT_yyyy_pppp_eeee enumeration; they range from zero through _EEEE_LLLL_FFFF______TTTT______NNNN_UUUU_MMMM_----_1111. SSSSEEEEEEEE AAAALLLLSSSSOOOO _eeee_llll_ffff______bbbb_eeee_gggg_iiii_nnnn(3E), _eeee_llll_ffff______cccc_nnnn_tttt_llll(3E), _eeee_llll_ffff______eeee_nnnn_dddd(3E), _eeee_llll_ffff______eeee_rrrr_rrrr_oooo_rrrr(3E), _eeee_llll_ffff______ffff_iiii_llll_llll(3E), _eeee_llll_ffff______ffff_llll_aaaa_gggg(3E), _eeee_llll_ffff______ffff_ssss_iiii_zzzz_eeee(3E), _eeee_llll_ffff______gggg_eeee_tttt_aaaa_rrrr_hhhh_dddd_rrrr(3E), _eeee_llll_ffff______gggg_eeee_tttt_aaaa_rrrr_ssss_yyyy_mmmm(3E), _eeee_llll_ffff______gggg_eeee_tttt_bbbb_aaaa_ssss_eeee(3E), _eeee_llll_ffff______gggg_eeee_tttt_dddd_aaaa_tttt_aaaa(3E), _eeee_llll_ffff______gggg_eeee_tttt_eeee_hhhh_dddd_rrrr(3E), _eeee_llll_ffff______gggg_eeee_tttt_iiii_dddd_eeee_nnnn_tttt(3E), _eeee_llll_ffff______gggg_eeee_tttt_pppp_hhhh_dddd_rrrr(3E), _eeee_llll_ffff______gggg_eeee_tttt_ssss_cccc_nnnn(3E), _eeee_llll_ffff______gggg_eeee_tttt_ssss_hhhh_dddd_rrrr(3E), _eeee_llll_ffff______hhhh_aaaa_ssss_hhhh(3E), _eeee_llll_ffff______kkkk_iiii_nnnn_dddd(3E), _eeee_llll_ffff______nnnn_eeee_xxxx_tttt(3E), _eeee_llll_ffff______rrrr_aaaa_nnnn_dddd(3E), _eeee_llll_ffff______rrrr_aaaa_wwww_ffff_iiii_llll_eeee(3E), _eeee_llll_ffff______ssss_tttt_rrrr_pppp_tttt_rrrr(3E), _eeee_llll_ffff______uuuu_pppp_dddd_aaaa_tttt_eeee(3E), _eeee_llll_ffff______vvvv_eeee_rrrr_ssss_iiii_oooo_nnnn(3E), _eeee_llll_ffff______xxxx_llll_aaaa_tttt_eeee(3E), _aaaa_...._oooo_uuuu_tttt(4) _aaaa_rrrr(4) The chapter ``Object Files'' in _U_N_I_X _S_Y_S_T_E_M _V _R_E_L_E_A_S_E _4 _P_r_o_g_r_a_m_m_e_r'_s _G_u_i_d_e: _A_N_S_I _C _a_n_d _P_r_o_g_r_a_m_m_i_n_g _S_u_p_p_o_r_t _T_o_o_l_s, published by Prentice Hall, ISBN 0-13-933706-7. NNNNOOOOTTTTEEEESSSS The standard SVR4 _e_l_f man page mentions processor-dependent header files with names of the form _<<<<_ssss_yyyy_ssss_////_eeee_llll_ffff______N_A_M_E_...._hhhh_>>>> where _N_A_M_E is a processor name in a table, such as _MMMM_3333_2222. There are no such header files in _I_R_I_X. A 32-bit application can construct 64-bit binaries using functions defined on the above-mentioned man pages. However the man pages and certain books published on SVR4 specifically document fields in the Elf_Data structure as long. This restricts the generated object files (even 64-bit object files) to have 32-bit values at most when constructed by a 32-bit application. The resulting object file is always 64-bit clean (the documented 32-bit fields are only too small during construction of the object file, not too small in the object file itself). This matters, for example, in the Fortran compiler where the _b_s_s section might need to be greater than 32-bits. See /usr/include/libelf.h _f_o_r _t_h_e _d_e_f_i_n_i_t_i_o_n(_s) PPPPaaaaggggeeee 4444 EEEELLLLFFFF((((3333EEEE)))) EEEELLLLFFFF((((3333EEEE)))) _o_f _E_l_f__D_a_t_a. To overcome this difficulty, the generating application should be compiled with the preprocessor flag _LIBELF_XTND_64 defined to all compilation units and should link to -lelf_xtnd and -ldwarf_xtnd instead of -lelf and -ldwarf. If this is done, the definition of the fields in the Elf_Data changes to 64 bits. This change permeates the definition of an Elf * (even though the definition of Elf* is opaque to the application), requiring the application build to be completely consistent and define _LIBELF_XTND_64 everywhere in the application build and to link with -lelf_xtnd and -ldwarf_xtnd instead of -lelf and -ldwarf. It is just possible that by compiling with _LIBELF_XTND_64 visible in some compilation units but not others an application could manage to pass an _EEEE_llll_ffff _**** or other libelf structure created without _LIBELF_XTND_64 _iiii_nnnn_tttt_oooo _aaaa _llll_iiii_bbbb_eeee_llll_ffff _ffff_uuuu_nnnn_cccc_tttt_iiii_oooo_nnnn _cccc_aaaa_llll_llll _cccc_oooo_mmmm_pppp_iiii_llll_eeee_dddd _wwww_iiii_tttt_hhhh ______LLLL_IIII_BBBB_EEEE_LLLL_FFFF______XXXX_TTTT_NNNN_DDDD______6666_4444. Or vice-versa. The result will surely be chaos. _LIBELF_XTND_64 is irrelevant to any 64-bit application and the -lelf_xtnd and -ldwarf_xtnd are not needed, since 64-bit applications can build true 64-bit object files without defining _LIBELF_XTND_64. Applications which only read 64-bit object files need not use _LIBELF_XTND_64 since the section headers, program headers, and data of the file have 64-bit fields without _LIBELF_XTND_64 being defined. PPPPaaaaggggeeee 5555 
